Об’єктно-орієнтовне Проектування
Резюме п’ятого заняття курсу «UX Architecture» в Projector.
Необачливі продуктові дизайнери вимушені регулярно перепроектовувати свої інтерфейси, оскільки не розуміють як продукти будуються під капотом.
Останні роки майже всі цифрові продукти реалізовуються по методологіїї ООП — об’єктно-орієнтовного програмування (проектування, аналізу, дизайну).
Коли дизайнер курця чує «Об’єкт», в його очах одразу постають кнопки, поля, тексти, зображення й інші візуальні об’єкти інтерфейсу, однак ООП — не про них. Власне, тому ці хлопці й постійно в запарці формату «це не так працює».
Більшість дизайнерів міркують візуально. Як результат — інтерфейс вступає в конфліет в реалізацією під капотом, що призводить до нежиттєздатного продукту.
З іншого боку, дизайнер здорової людини розуміє об’єктно-орієнтовний підхід, й використовує його для проектування успішних продуктів, що працюють стабільно, й успішно розвиваються вшир та вглиб.
Якщо говорити сухою мовою, то об’єктно-орієнтовне проектування — це побудова системи взаємодії між об’єктами та користувачами продукту.
В системах завжди існує декілька типів користувачів з різними потребами. Не завжди зрозуміло, кому показувати який інтерфейс та з якими можливостями.
На жаль, з часом будь-який успішний цифровий проект розширяється, горизонтально та вертикально. Проблема в тому, що при розширенні його складність збільшується по експоненті, й тримати все в голові стає неможливо, однак проектувальникам це необхідно для побудови успішного продукту.
Дизайн-інженер здорової людини може приймати успішні продуктові рішення за допомогою ООП. В нього нічого не зламається з часом, він нічого не забуде в системі, а під час реалізації буде менше багів та недомислень.
Мега-матриця
Як говорили вище, цифровий продукт — це схема взаємодії між об’єктами та користувачами. За десятки років ООП з’явилося сотні спеціальних інструментів, які дозволяють викласти цю схему візуально, щоб поділитися зі своїми колегами та керівництвом.
Існуючі були занадто складні та пристосовані до потреб розробників й системних архітекторів, тому мені було зручніше придумати свій особистий «велосипед» для проектувальників.
Назвав його «Мега-матрицею». Вона дозволяє не тримати все в голові, й швидко підвіряти свої продуктові рішення у разі потреби. Не кажучі вже про те, що при розширенні можливостей продукту її легко підтримувати в актуальному стані, й передавати свої знання колегам.
Простіше за все Мега-матрицю представити у вигляді таблиці з двома осями.
Оскільки схема має масштабуватися з часом, то її побудова не випадкова.
Горизонтально ми розміщуємо ролі користувачів продукту. Частіше за все їх в системі менше десятку, й відповідно вони всі влізають в екран, й для аналізу схеми достатньо тільки скроллити сторінку вниз.
Вертикально визначаємо класи об’єктів та методи взаємодії з ними.
На перетині методів та ролей визначаємо їх рівні доступів. Так, абсолютно природньо ми виходимо на класичну RBAC-модель розподілення доступів в системі. Програмісти подякують.
В примітках до різних класів ми визначаємо їх властивості.
Прохаю звернути увагу: на відміну від воркфлоу, тут ми говоримо про продукт, а не бізнес.
Тепер поговоримо детальніше про кожну складову матриці.
Суб’єкти
Тут все просто — це ролі користувачів продукту, які з ним взаємодіять.
У прикладі з автомобілем користувачами виступають прості перехожі, водій, передній та задні пасажири, а також людина, яка лежить зв’язана в багажнику.
Варто звернути увагу, що в системах майже завжди присутня роль Visitor та System, тому раджу при проектування стартувати саме з них.
Вони поділяються на фронтофісних та бекофісних, тобто таких, хто бачить лише вітрину (користувачі, відвідувачі, тощо), й тих працює під капотом (співробітники компанії різних рівнів, тощо).
Цікавий парадокс: користувачі продукту з точку зору ООП також виступають класами об’єктів Users.
Раджу розфарбувати їх в різні кольори. На подальших етапах проектування великих продуктів ці кольори неодноразово знадобляться. Важливо, щоб вони були уніфікованими.
Класи об’єктів
В світі існують мільярди автомобілей та трильйони дерев.
Однак ми вміємо відрізняти зелені дерева від зеленого автомобілю, оскільки вони мають разні властивості. Як мінімум, дерево може бутим пишним, а автомобіль швидким.
В прикладі вище: «Автомобіль» та «Дерево» — це назви класів об’єктів. Це назва такого набору спільних характеристик та способів взаємодії, за допомогою якого можна описати будь-яке дерево та всі автомобілі світу.
Зверніть увагу, коли ми говоримо «клас об’єктів» мова йде про всі автомобілі світу, а не якийсь конкретний.
Де закінчується один клас, й починається інший?
- В них різні набори характеристик. Ми описуємо автівки та дерева різними способами.
- Об’єкти цього класу можуть існувати без об’єктів іншого класу. Дерева прекрасно жили міль’ярди років до появи автомобілів.
- Відрізняються способи взаємодії. Дерева можна закопувати в землю, автівки не варто (хоча також можна, якщо ви довбойоб).
Знання класів об’єктів в системі — найпростіший шлях побудови інтуітивної навігації в продукті.
Об’єкти
Від абстрактних всіх автомобілей світу перейдемо до автомобілей конкретних.
Ми вже знаємо, що клас об’єктів наслідує своїм об’єктам певні характеристики. Однак характеристики можуть мати різні значення.
- Автомобілі бувають червоними та чорними (колір).
- Великими та маленькими (габарити).
- Важкими та легкими (вага).
- Кожен автомобіль має свій кузовний номер та номер двигуна (ID).
Всі автомобілі мають колір, габарити та вагу. І саме цим (і ще купою характеристик) вони й відрізняються, створюючи мільйони незалежних унікальних комбінацій.
Кожна автівка світу — це окремий об’єкт класу «Автомобіль». Незалежно від того, це 3-літровий дизельний чорний Infinity QX70, чи Mazda CX-5 з 2,5 бензиновим двигуном.
В будь-якого об’єкту є хоча б одне унікальне значення хоча б одного параметру. Наприклад, в усіх автомобілів є VIN-номер — код, який виступає унікальним ідентифікатором.
Методи взаємодії
З кожним об’єктом певного класу можна щось робити. Автомобіль можна відчиняти та зачиняти. Заходити всередину, сідати на крісло. Завести та вирушити в путь.
Методи — конкретні способи взаємодії суб’єктів з класом, або конкретним об’єктом, чи навіть їх переліком. Частіше за все методи використовують люди для задовільнення своїх потреб, однак інколи методи використовує сама система автоматично, за певних передумов.
В цифрових системах майже стандартними методами є CRUD — Create, Read, Update та Delete. Підвантажити нові об’єкти в перелік, посортувати та пофільтрувати його — також яскраві приклади методів, які зустрічаються в усіх продуктах.
Властивості класів
Це штуки, якими ми описуємо певний клас об’єктів (не конкретний об’єкт).
Наприклад: висота, вага, колір, матеріал, категорія, автор, тощо.
У властивостей можуть бути різні значення. Вони задаються автоматично та вручну. Змінюються так само.
Який колір автівки — зелений, чорний або червоний?
Який розмір футболки — S, M чи L?
В цифрових продуктів існують базові властивості кожного об’єкту завдяки певним технічним особливостям. Можна почати з них.
- ID
- Дата створення
- Дата останньої зміни
- Творець
В залежності від контексту та класу об’єктів, базові властивості разюче відрізняються.
Рівні доступів
Різні люди використовують наш продукт по-різному. Одному потрібно модерувати коментарі, а іншому відповідати на питання клієнтів. Третій налаштовує платіжні системи, а четвертий за цим балаганом слідкує.
Авжеж, в різних учасників бізнес-процесів також відрізняються рівні доступу до даних, щоб кур’єр піцерії не міг бачити її бізнес-показники, й по-п’яні не розповів їх знайомому, а той своєму знайомому.
На матриці ми визначаємо яка роль користувачів системи до яких методів має доступ. Це спрощує життя при проектування інтерфейсу, оскільки одразу стає зрозумілим, що звідки потрібно викинути та сховати для різних користувачів.
Навіщо ООП дизайн-інженеру
- Кращі продуктові рішення.
- Здоровий глузд, не потрібно тримати все в голові.
- Система розвивається під контролем.
- Будувати таксономію та навігацію в рази простіше та швидше.
- Простіше передавати інформацію іншим учасникам розробки.
- Декілька дизайнерів можуть спокійно розвивати інтерфейс без страху про майбутнє продукту.
- Продукт роки не потребуватиме радикальної перепроектування інтерфейсу, оскільки буде масштабованим вшир та вглиб.
